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Abstract 


This document obsoletes RFC 2374, "An IPv6 Aggregatable Global 
Unicast Address Format". It defined an IPv6 address allocation 
structure that includes Top Level Aggregator (TLA) and Next Level 
Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA 
structure historic. 


1. Introduction 


RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format", 
defined an IPv6 address allocation structure that includes TLA and 
NLA. This document replaces RFC 2374, and makes RFC 2374 and the 
TLA/NLA structure historic. 


2. TLA/NLA Made Historic 


The TLA/NLA scheme has been replaced by a coordinated allocation 
policy defined by the Regional Internet Registries (RIRs) [IPV6RIR]. 


Part of the motivation for obsoleting the TLA/NLA structure is 
technical; for instance, there is concern that TLA/NLA is not the 
technically best approach at this stage of the deployment of IPv6. 
Moreover, the allocation of IPv6 addresses is related to policy and 
to the stewardship of the IP address space and routing table size, 
which the RIRs have been managing for IPv4. It is likely that the 
RIRs’ policy will evolve as IPv6 deployment proceeds. 
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The IETF has provided technical input to the RIRs (for example, 
[RFC3177]), which the RIRs have taken into account when defining 
their address allocation policy. 


RFC 2374 was the definition of addresses for Format Prefix 001 
(2000::/3) which is formally made historic by this document. Even 
though currently only 2000::/3 is being delegated by the IANA, 
implementations should not make any assumptions about 2000::/3 being 
special. In the future, the IANA might be directed to delegate 
currently unassigned portions of the IPv6 address space for the 
purpose of Global Unicast as well. 


The Subnet Local Aggregator (SLA) field in RFC 2374 remains in 
function but with a different name in [ARCH]. Its new name is 
"subnet ID". 


3. Address Format 


The general format for IPv6 global unicast addresses as defined in 
"IP Version 6 Addressing Architecture" [ARCH] is as follows: 


128-n-m bits | 


where the global routing prefix is a (typically 
hierarchically-structured) value assigned to a site (a cluster of 
subnets/links), the subnet ID is an identifier of a subnet within the 
site, and the interface ID is as defined in section 2.5.1 of [ARCH]. 
The global routing prefix is designed to be structured hierarchically 
by the RIRs and ISPs. The subnet field is designed to be structured 
hierarchically by site administrators. 


[ARCH] also requires that all unicast addresses, except those that 
start with binary value 000, have Interface IDs that are 64 bits long 


and to be constructed in Modified EUI-64 format. The format of 
global unicast address in this case is: 
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where the routing prefix is a value assigned to identify a site (a 
cluster of subnets/links), the subnet ID is an identifier of a subnet 
within the site, and the interface ID is a modified EUI-64 format as 
defined in [ARCH]. 


An example of the resulting format of global unicast address under 
the 2000::/3 prefix that is currently being delegated by the IANA and 
consistent with the recommendations in RFC 3177 is: 
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6. Security Considerations 


IPv6 addressing documents do not have any direct impact on Internet 
infrastructure security. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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